Feature Switching Kits

ABSTRACT

A system and method for feature switching in software applications. A feature switching action (FSA) is received and at least one user device is identified based on the received FSA. At least one feature switching instruction (FSI) is generated based on the received FSA and the FSI is sent to at least one of the identified user devices. A feature switching instruction response (FSIR) is received from each user device that received a FSI and a feature switching action response (FSAR) is generated based on the received FSIRs.

This application is a continuation of, and claims the benefit of, U.S.patent application Ser. No. 17/128,851, filed Dec. 21, 2020, which is acontinuation of, and claims the benefit of, U.S. patent application Ser.No. 16/208,080, filed Dec. 3, 2018, which is a divisional applicationof, and claims the benefit of, U.S. patent application Ser. No.15/250,753, filed Aug. 29, 2016, which claims the benefit of U.S.Provisional Application No. 62/211,552, filed Aug. 28, 2015, the entirecontents of each which are incorporated herein by reference.

BACKGROUND

A software development kit (SDK) is a set of tools used to createapplications for particular platforms. Software application developersoften incorporate third-party software development kits (SDKs) intotheir product to enhance its functionality and marketability.

SUMMARY

In one example, a system and method for feature switching includesdefining a plurality of service software development kits (serviceSDKs), including a first service SDK, wherein each service SDK isassociated with a service and includes one or more features associatedwith the service, developing an application having one or more of theservice SDKs, including the first service SDK, and executing theapplication on a user device, wherein executing includes determining ifthe service associated with the first service SDK is available andswitching off one or more features of the first service SDK if theservice is unavailable.

In another example, a method for feature switching in softwareapplications includes receiving a service status report (SSR) from aservice provider, determining that a feature adjustment is requiredbased on the received SSR, generating, based on determination, a featureswitching action (FSA), sending the FSA to a software development kit(SDK) platform and receiving a feature switching action response (FSAR)from the SDK platform.

In another example, a method for feature switching in softwareapplications includes receiving a service status report (SSR) from aservice provider, determining that a feature adjustment is requiredbased on the received SSR, generating, based on the determination, afeature switching action advice (FSAA), sending the FSAA to a commandauthority for validation, receiving a feature switching action (FSA)from the command authority, and sending a feature switching actionresponse (FSAR) to the command authority.

In another example, a method for feature switching in softwareapplications includes receiving a feature switching action (FSA) from acommand authority, identifying at least one user device based on thereceived FSA, generating at least one feature switching instruction(FSI) based on the received FSA, sending the FSI to at least oneidentified user device, receiving a feature switching instructionresponse (FSIR) from the at least one identified user device, generatinga feature switching action response (FSAR) based on the received FSIRand sending the FSAR to the command authority.

In another example, a method for feature switching in softwareapplications includes receiving a feature switching instruction (FSI)from a software development kit (SDK) platform, identifying, based onthe received FSI, a service SDK identifier, at least one featureidentifier, and at least one feature set value, determining that areplacement user interface (UI) skin is required to fulfill the FSI,obtaining, based on the determination, the replacement UI skin, applyingthe replacement UI skin and updating at least one feature property;generating a feature switching instruction response (FSIR), and sendingthe FSIR to the SDK platform.

In another example, a method for feature switching in softwareapplications includes receiving, at a device, one or more featureswitching instructions (FSIs) from a software development kit (SDK)platform, wherein each FSI includes a service SDK identifier, a featureidentifier and a feature set value, wherein each FSI identifies afeature within a service SDK as a function of the service SDK identifierand the feature identifier, applying an adjustment to the respectivefeature identified by each FSI based on the feature set value in therespective FSI, generating a feature switching instruction response(FSIR), and sending the FSIR to the SDK platform.

In another example, a system includes at least one processor and acomputer-readable storage medium storing instructions that, whenexecuted, cause the at least one processor to receive a featureswitching action (FSA), identify at least one user device based on thereceived FSA, generate at least one feature switching instruction (FSI)based on the received FSA, send the FSI to at least one of theidentified user devices, receive a feature switching instructionresponse (FSIR) from the at least one identified user device, andgenerate a feature switching action response (FSAR) based on thereceived FSIR.

In another example, a device includes at least one processor and acomputer-readable storage medium storing instructions that, whenexecuted, cause the at least one processor to receive, from an externalsource, one or more feature switching instructions (FSIs), wherein eachFSI includes a service SDK identifier, a feature identifier and afeature set value, wherein each FSI identifies a feature within aservice SDK as a function of the service SDK identifier and the featureidentifier, apply an adjustment to the feature identified by each FSIbased on the feature set value in the FSI, generate a feature switchinginstruction response (FSIR), and send the FSIR to the external source.

In yet another example, a computer-readable storage medium storesinstructions that, when executed, cause at least one processor toreceive a feature switching action (FSA), identify at least one userdevice based on the received FSA, generate at least one featureswitching instruction (FSI) based on the received FSA, send the FSI toat least one identified user device, receive a feature switchinginstruction response (FSIR) from the at least one identified userdevice, and generate a feature switching action response (FSAR) based onthe received FSIR.

The feature switching system and method described below provides amodular mechanism for accessing services via service SDKs. This modularmechanism may be used to simplify the addition of services toapplications running on user devices, to efficiently introduce both newservices and new features in existing services in real-time withoutinterruption and to gracefully handle failure when a service isunavailable or degraded. The system and method becomes even morepowerful when combined with a service SDK platform that controlsdeployment, monitoring and configuration of the service SDKs used in theapplications installed on the user device as detailed below. Softwaredevelopers may access the service SDK platform to include service SDKsin their applications.

The details of one or more examples of the disclosure are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the disclosure will be apparent from thedescription and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 shows a feature switching system in accordance with one or moreaspects of the present disclosure.

FIG. 2A shows a developer device in accordance with one or more aspectsof the present disclosure.

FIG. 2B shows a user device in accordance with one or more aspects ofthe present disclosure.

FIG. 2C shows a service software development kit (SDK) in accordancewith one or more aspects of the present disclosure.

FIG. 3A shows an example of a degree of granularity granted in featureswitching in accordance with one or more aspects of the presentdisclosure.

FIG. 3B shows an example of a degree of granularity granted in featureswitching in accordance with one or more aspects of the presentdisclosure.

FIG. 4A shows a method for generating a feature switching action (FSA)in accordance with one or more aspects of the present disclosure.

FIG. 4B shows a method for generating a feature switching action advice(FSAA) in accordance with one or more aspects of the present disclosure.

FIG. 5 shows a method for generating a feature switching instruction(FSI) and a feature switching action response (FSAR) in accordance withone or more aspects of the present disclosure.

FIG. 6A shows an example of a degree of granularity granted in featureswitching in accordance with one or more aspects of the presentdisclosure.

FIG. 6B shows an example of a degree of granularity granted in featureswitching in accordance with one or more aspects of the presentdisclosure.

FIG. 6C shows an example of a degree of granularity granted in featureswitching in accordance with one or more aspects of the presentdisclosure.

FIG. 7 shows a method for generating a feature switching instructionresponse (FSIR) in accordance with one or more aspects of the presentdisclosure.

FIG. 8 shows one example of the execution of a feature switchinginstruction (FSI) on a user device in accordance with one or moreaspects of the present disclosure.

FIG. 9 shows one example of the execution of a feature switchinginstruction (FSI) on a user device in accordance with one or moreaspects of the present disclosure.

FIG. 10 shows a computing system in accordance with one or more aspectsof the present disclosure.

DETAILED DESCRIPTION

Specific aspects of the present disclosure will now be described indetail with reference to the accompanying figures. In the followingdetailed description of aspects of the present disclosure, numerousspecific details are set forth in order to provide a more thoroughunderstanding of the invention. However, it will be apparent to one ofordinary skill in the art that the invention may be practiced withoutthese specific details. In other instances, well-known features have notbeen described in detail to avoid unnecessarily complicating thedescription.

Throughout the application, ordinal numbers (e.g., first, second, third,etc.) may be used as an adjective for an element (i.e., any noun in theapplication). The use of ordinal numbers is not to imply or create anyparticular ordering of the elements nor to limit any element to beingonly a single element unless expressly disclosed, such as by the use ofthe terms “before”, “after”, “single”, and other such terminology.Rather, the use of ordinal numbers is to distinguish between theelements. By way of an example, a first element is distinct from asecond element, and the first element may encompass more than oneelement and succeed (or precede) the second element in an ordering ofelements.

In the following description of FIGS. 1-10 , any component descriptionwith regard to a figure, in various aspects of the present disclosure,may be equivalent to one or more like-named components described withregard to any other figure. For brevity, descriptions of thesecomponents will not be repeated with regard to each figure. Thus eachand every example of the components of each figure is incorporated byreference and assumed to be optionally present within every other figurehaving one or more like-named components. Additionally, in accordancewith various aspects of the present disclosure, any description of thecomponents of a figure is to be interpreted as an optional embodiment,which may be implemented in addition to, in conjunction with, or inplace of the embodiments described with regard to a correspondinglike-named component in any other figure.

Developers often develop applications for user devices (e.g., mobiledevices) operating within a network. Such applications, when executed onthe user devices, often access services provided by service providersoperating on the network via software development kits (SDKs) embeddedin or otherwise used by the applications.

Applications distributed to user devices tend to include static codewith fixed features. Such an approach simplifies distribution andmaintenance of such code at the cost of adaptability. What are describedbelow are example methods and systems for enabling and managingreal-time feature switching in deployed software applications via an SDKplatform. Such an approach allows the application developer todynamically add and improve services within their applications.

In one example approach, a developer enables feature switching byincluding feature switches in the application code. One can use suchswitches to, for example, slowly enable new features in existingapplications or to turn on or off features in response to changingconditions. In one non-limiting example, an application executing on amobile device may access three different services. For instance, thethree services include an analytics service, a logging service and anaggregation service. If one of the services is unavailable, it would beadvantageous to be able to disable that feature in the application. Inone example approach, the service provider disables the feature via anSDK platform. In another such example approach, a command authoritydetermines if a feature should be disabled and communicates that to theappropriate user devices. In yet another example approach, a processorreceives an indication from a service provider that a feature should bedisabled. The processor then determines if the feature should bedisabled.

FIG. 1 shows a feature switching system (100) in accordance with one ormore aspects of the present disclosure. In one or more aspects of thepresent disclosure, the feature switching system (100) includesdeveloper devices (102), service providers (104), user devices (106),and a software development kit (SDK) platform (108). As shown in FIG. 1, the developer devices (102) and user devices (106) are operativelyconnected to the service providers (104) and the SDK platform (108).Aside from being operatively connected to the developer devices (102)and the user devices (102), the service providers (104) are alsooperatively connected to the SDK platform (108). The connections betweenthe various components may be wired and/or wireless, direct or indirect,temporary, permanent and/or intermittent, through a local area or widearea network, or have any other type of connection or a combinationthereof. Further, additional and/or alternative connections may existwithout departing from the scope of what is described herein. Each ofthe above components is described below.

In one or more aspects of the present disclosure, the developer devices(102) and the user devices (106) each correspond to any combination ofhardware, software, and/or firmware, such as shown and discussed belowwith respect to FIG. 10 . The developer devices (102) and user devices(106) may correspond to a same type of device or to heterogeneousdevices. Further, each of the aforementioned devices may correspond to asingle device or multiple devices.

In one or more aspects of the present disclosure, a developer device(102) is a device that is used to develop a software application(discussed below). An application developer is a user or group of usersthat creates, updates, and/or manages the code of the softwareapplication. Further, an application developer and a developer devicemay additionally manage or authorize real-time changes to releases ofthe software application as needed. In such a scenario, the developerdevice may include functionality to enact feature switching through anSDK platform (108). Developer devices are discussed in further detailbelow and in FIG. 2A.

The software application is any computer program product that isdeveloped by an application developer. The term software application mayinclude different versions and/or editions of the same softwareapplication. In one or more aspects of the present disclosure, thesoftware application includes multiple features. Each feature is adistinct attribute of the software application that may or may not betransparent to the end-user operating the user device. In other words,the features of the software application may be observable to theend-user; or alternatively, the features of the software application maybe hidden from the end-user. For example, a feature represented as adisplayed component in a graphical user interface (GUI) is a featurethat is observable to the end-user. In another example, a feature thatimpacts the behavior of a provided service, such as only impacting theprovided content or data utilized by the software application, is afeature that is hidden from the end-user.

In one or more aspects of the present disclosure, a user device (106) isa device used by market users of the software application. A market useris a customer of the software application. For example, the market usermay be a purchaser of the software application and/or an entity thatacquires a general released version of the software application.Furthermore, the market user utilizes the software application per itsintended use. User devices are discussed in further detail below and inFIG. 2B.

Continuing with FIG. 1 , in one or more aspects of the presentdisclosure, each service provider (104) may execute on one or morecomputing devices (e.g., a server, a mainframe, a personal computer(PC), a laptop, etc.) that may not be of the same type or located at thesame physical site. Each service provider (104) provides one or moreservices, functions, content, or capabilities that can be requested by acomputing device (e.g., user device (106)) and/or by a softwareapplication external to the service provider (104). Furthermore, eachservice provider (104) may provide notifications to applicationdevelopers (e.g., via a developer device and/or via the SDK platform)pertaining to the availability and/or functionality of the providedservices, functions, content, or capabilities.

As shown in FIG. 1 , the developer devices (102), the service providers(104), and the user devices (106) are connected to a SDK platform (108).In general, the SDK platform (108) corresponds to hardware, software,firmware, or a combination thereof that provides support services forSDKs. For example, the SDK platform may provide a marketplace for SDKsand provide server side services for executing SDKs

Often, an application operating in one of user devices 106 in system 100will have many different SDKs. In such a situation, it can beadvantageous to manage each SDK from a single platform. One such exampleplatform 108 is shown in FIG. 1 . In one example approach, featureswitching may be a core feature of SDK platform 108. Such an approach isadvantageous because the approach reduces complexity for the applicationdeveloper and for the SDK providers that are contributing to theplatform by providing a single point of SDK management. In other words,an SDK developer may create an SDK and send the SDK to the SDK platform.The SDK platform may provide SDK marketplace services, such that anapplication developer may purchase or otherwise obtain the SDK andincorporate the SDK into a software application. An SDK is a set ofsoftware development tools that assist in the creation of softwareapplications. Additionally, in one example approach, the SDK platform(108) includes functionality to track the deployment of SDKs across userdevices (106). That is to say, the SDK platform includes functionalityto determine which SDKs, and subsequently, which features associatedwith a software application, are in each connected user device.

In one example approach, the SDK platform (108) may also provide anapplication marketplace for software applications. An application marketis a virtual network space, supported by hardware and software thatconnects consumers of software applications to developers of softwareapplications, and facilitates the exchange of software applications. Inat least some example approaches, the application market is a publicmarket that is accessible via the Internet.

Continuing with the SDK platform (108), the SDK platform (108) includesa data repository (110). The data repository (110) is any type ofstorage unit and/or device (e.g., a file system, database, collection oftables, or any other storage mechanism) for storing data. Further, thedata repository (110) may include multiple different storage unitsand/or devices. The multiple different storage units and/or devices mayor may not be of the same type or located at the same physical site. Thedata repository (110) includes functionality to store one or more datum(112, 114), which, in one or more example approaches, may includeunprocessed and processed information.

Unprocessed data is raw data that is gathered from the SDKs embedded inthe software application that is, in turn, executing on the userdevice(s). For example, unprocessed data may include, but is not limitedto, for each SDK in the software application: an amount of time in whicheach feature is executed, identification of the subset of featuresexecuted, and the frequency in which the associated service has beenused/accessed. A subset as used in this application includes all, part,or none. Thus, a subset of features of an SDK may be all the features ofthe SDK, part of the features of the SDK, or none of the features of theSDK. Unprocessed data may also include, representing an overview of theSDK platform and/or the feature switching system entirely: the number ofuser devices with a particular software application, SDK, and/or featureinstalled, the number of user devices running a specified operatingsystem (OS), the general geographical location the software applicationis executing at, the frequency of which the software application hasbeen opened, identification of which user devices favored which SDKsand/or features, and any other unprocessed data.

Processed data may include statistics or metrics about the unprocesseddata. For example, processed data may include totals and/or proportions.The totals may include: the total elapsed execution time of the softwareapplication, SDKs, and features, the total number of user devices withina specified geographic region (e.g., city, state, country, etc.), andthe total number of users (e.g., user devices) expressing favoritismtowards a particular service, feature, or alternative. Proportions,which includes the conveyance of data through percentages and/or rates,may include: the amount of execution time pertaining to a feature or aSDK/service in comparison to the total amount of time the softwareapplication has been executing, the distribution of user devicesexecuting the software application across various definable geographiclocations, and the rate of users (e.g., user devices) actively accessingparticular services within a specified period of time (e.g., daily,weekly, monthly, etc.).

The above discussion is representative of only a few types ofunprocessed and processed data that may be stored in the data repository(110). Additional and/or alternative unprocessed and processed data maybe collected and/or exist without departing from what is describedherein.

FIG. 2A shows a developer device (200) in accordance with one or moreaspects of the present disclosure. In one or more example approaches,the components of FIG. 2A may be implemented in hardware, software,firmware, or a combination thereof. As shown in FIG. 2A, the developerdevice (200) may include an integrated development environment (IDE)(202) and a developer user interface (UI) (204). Each of thesecomponents is discussed below.

The IDE (202) is a collection of one or more tools that facilitates thedevelopment of a software application. For example, the tools in the IDE(202) may include tools, such as a code editor, compiler, debugger, andother tools used in the development of a software application. In one ormore example approaches, the IDE (202) includes an application coderepository (206), and one or more service plugins (208, 210). Theapplication code repository (206) is a data repository for storingapplication source code, a compiled binary, intermediate object code, orany other type of code. Each of the service plugins (208, 210) is anextension to the IDE that connects to their respective service(discussed above). Each of the service plugins (208, 210) may assist inadding their respective SDK to the software application andcommunicating with the respective service to obtain data from theservice.

The developer UI (204) is an interface (e.g., graphical user interfaceand/or application programming interface) for the developer device (200)that facilitates access to the SDK platform. For example, the developerUI (204) may include interface widgets and functionality to receive,directly or indirectly, from the application developer, the softwareapplication, parameters to identify user devices that are running thesoftware application, and parameters for enabling and managing featureswitching in real-time at any granularity. In one or more exampleapproaches, the developer UI (204) includes a dashboard (212). In one ormore example approaches, the dashboard (212) includes the presentationof data resulting from the employment of services provided. Referring tothe analytics service example (discussed above), the dashboard (212) mayinclude charts, graphs, and other GUI widgets to present analytics.

FIG. 2B shows a user device (220) in accordance with one or more aspectsof the present disclosure. In one or more example approaches, thecomponents of FIG. 2B may be implemented in hardware, software,firmware, or a combination thereof. As shown in FIG. 2B, the user device(220) may include a software application (222) (discussed above). Thesoftware application (222) on the user device (220) is a version of thesoftware application for use by the market user. In one or more exampleapproaches, the software application (222) includes one or more serviceSDKs (224, 226). The service SDKs (224, 226) each includes functionalityto gather data pertinent to, and relay that data towards, theirrespective services. Using the analytics service example mentionedearlier, the software application (222) includes an analytics serviceSDK amongst the service SDKs (224, 226) embedded within. Subsequently,the analytics service SDK includes functionality to gather dataregarding usage of the software application (222) on the user device(220), as well as the functionality to forward that usage data to theanalytics service.

While FIGS. 2A and 2B show a configuration of components, otherconfigurations may be used without departing from what is describedherein. For example, various components may be combined to create asingle component. As another example, the functionality performed by asingle component may be performed by two or more components.

FIG. 2C shows a service SDK (240) in accordance with one or more aspectsof the present disclosure. As shown in FIG. 2C, the service SDK (240)may include one or more features (242, 244), a feature switching manager(246), and a resources repository (248). Each of these components arediscussed below.

In one or more example approaches, the service SDK (240) includes one ormore features (242, 244). As mentioned above, the one or more features(242, 244) are representative of the distinct attributes of a softwareapplication; more so, features are the distinct segments defining aprovided service used within the software application. Further, afeature may be interacted with via a binary and/or through a variablefashion. In other words, in one embodiment, the feature may be toggledto enable or disable (e.g., binary states) its function in the providedservice and subsequently, the software application. In anotherembodiment, the feature may variably restrict its influence orcontribution to the data/content utilized by the software application. Afeature may impact its respective service through any other mechanismwithout departing from what is described herein.

In one or more example approaches, the service SDK (240) includes afeature switching manager (246). In one or more example approaches, thefeature switching manager (246) is software construct serving as amanagement system purposed with executing received feature switchinginstructions (FSI) (discussed below). The feature switching manager(246) is the main body that implements the adjustments specified in theFSI and handles the employment of resources (i.e., UI skins, images,fonts, etc.) that are essential towards completing a feature switchingadjustment. Further, the feature switching manager (246), in one or moreexample approaches, reserves the functionality to update the propertiesof a feature (242, 244) (discussed below) based on the outcome ofexecuting the received FSI.

In one or more example approaches, the service SDK (240) includes aresources repository (248). The resources repository (248) is any typeof storage unit and/or device (e.g., a file system, database, collectionof tables, or any other storage mechanism) for storing data. Further,the resources repository (248) includes functionality to store resources(e.g., UI skins, images, etc.) critical to the successful execution offeature switching adjustments in one or more example approaches.

FIGS. 3A-3B show varying examples of degrees of granularity granted infeature switching, with respect to targeting attributes of a softwareapplication, in accordance with one or more aspects of the presentdisclosure. Further, each example degree of granularity portrayslike-named components common within each example. These commoncomponents include: (i) the software application (300A, 300B); (ii) oneor more service SDKs (302A, 302B, 304A, 304B) providing backendfunctionality of services used in the software application; and (iii)one or more features (306A, 306B, 308A, 308B) that comprise theservices, functions, contents, or capabilities associated with a serviceSDK. In the example presented in FIG. 3A, it is shown that featureswitching can target a subset of features associated with a providedservice. For example, due to some circumstance, a command authority(e.g., application developer, developer device, a separate system 100computer, a processor in the SDK platform) decides to disable onefeature (306A), such as a particular payment option amongst a pluralityof payment options, provided within a service such as a payment service.The example in FIG. 3B demonstrates that feature switching can extendbeyond just features, thus also being capable of targeting a subset ofservice SDKs (302B) as well. Service SDKs may require disablement inresponse to exceeding a set threshold of downtime experienced at theservice provider end.

FIGS. 4A-5 and 7 show flowcharts in accordance with one or more aspectsof the present disclosure. While the various steps in these flowchartsare presented and described sequentially, one of ordinary skill willappreciate that some or all of the steps may be executed in differentorders, may be combined or omitted, and some or all of the steps may beexecuted in parallel. Furthermore, steps may be performed actively orpassively. For example, some steps may be performed using polling or beinterrupt driven in accordance with one or more aspects of the presentdisclosure. By way of an example, determination steps may not require aprocessor to process an instruction unless an interrupt is received tosignify that a condition exists in accordance with one or more aspectsof the present disclosure. As another example, determination steps maybe performed by performing a test, such as checking a data value to testwhether a value is consistent with the tested condition in accordancewith one or more aspects of the present disclosure.

FIG. 4A shows a method for generating a feature switching action (FSA)in accordance with one or more aspects of the present disclosure. InStep 402, a service status report (SSR) is received from a serviceprovider. In one or more example approaches, a SSR may be implemented asa file or stream of data that is periodically generated and transmittedby a service provider. In this application, a file refers to data thatis stored in a storage device (see e.g., 1006 in FIG. 10 ) within itshost computing system (see e.g., 1000 in FIG. 10 ) and can be lateraccessed by a software application for processing. A stream of data (ordata stream) refers to data that is stored temporarily in buffersassociated with the hardware corresponding to the communication protocolthe data is encoded in. To exemplify the various formats that which datamay be delivered, in one example, the service provider may transmitdifferent granularities of binary data (e.g., ones and zeros) todisclose the different granularities of states (e.g., on and off,available and unavailable) associated with its provided service. In oneexample approach, the service provider may transmit a single binarydigit or bit that describes the state of its service as a whole (e.g.,1—service is up, 0—service is down). In another example approach, theservice may transmit a sequence of binary bits (e.g., bytes) to providea more detailed outlook on the state of its service, thus sharing theindividual states of each feature or attribute comprising its service(e.g., 111—all features are up, 010—the first and third features aredown). Additionally, the service provider may offer higher degrees ofgranularity with respect to the state of its provided service. Insteadof disclosing one of two possible states, as is the limitation oftransmitting binary data, the service provider, in one or more exampleapproaches, may deliver an SSR that includes metrics that further detailthe performance and reliability of its service and/or its attributes. Indoing this, the service provider allows for the customization of thebehavior that which feature switching occurs in the softwareapplication. In one or more example approaches, this customization iscarried out through comparison of the received metrics with presetthresholds or benchmarks, to which meeting any definable conditionresults in triggering a feature switching action (FSA) or not.

In Step 404, a determination is made whether information provided in thereceived SSR warrants that adjustment(s) of software applicationattributes take place. In one example approach, an adjustment maycomprise enabling or disabling at least a part of a service, therebyprompting a change in the software application user interface that isobservable to the end-user. In another example approach, an adjustmentmay comprise redefining the behavior of a service that is being providedto a user device. Said another way, a service may provide content ordata to a software application fed from numerous sources and anadjustment affecting the behavior of a provided service would, forexample, alter the contribution of each source towards that provideddata. In yet another example approach, an adjustment may refer tointroducing an additional source in contributing towards the dataprovided, followed by the redistribution of contributions between theexisting and new sources. In another example approach, an adjustment maycomprise a change in the configuration of service settings to conform toend-user preferences, which may or may not trigger visible modificationsto the software application user interface in addition to servicebehavioral changes. Other processes may comprise of an adjustmentwithout departing from what is described herein. Returning to thediscussion of FIG. 4A, if at least one attribute or feature of a serviceis identified as requiring an adjustment, the process proceeds to Step406; otherwise, it is deemed that feature switching is unnecessary andthe process ends. In one or more example approaches, the determinationstep may include: (i) processing the SSR, received in Step 402, toobtain quantifiable indicators revealing the most recent state of theprovided service; and (ii) comparing those indicators to correspondingreference values, resulting in action or inaction. In this application,processing of the SSR may denote any technique, such as parsing, bitwiseoperations, and/or any existing or new variants of data mining that mayfacilitate the separation of the afore-mentioned indicators, on thebasis of any specified granularity, from the SSR.

Continuing discussion of FIG. 4A, in Step 406, based on thedetermination presented in Step 404, a FSA is generated to addressinformation in the received SSR, which discloses the state of theprovided service. In one or more example approaches, the FSA may specifythe following information items: (i) a unique service provideridentifier, associated with the service provider from which the SSRoriginated, and used by the SDK platform to identify the appropriateservice SDK in its instructions to the user device(s) (discussed below);(ii) one or more feature identifier and set value pairs, each presentinga feature in the designated service SDK and the desired adjustmentapplied to that feature; and (iii) one or more unique user deviceidentifiers corresponding to the set of user devices the adjustments aretargeted to affect.

In Step 408, the FSA, generated in Step 406, is sent to the SDKplatform. In Step 410, following the completion of processes shown anddiscussed below with respect to FIGS. 5 and 7 , a feature switchingaction response (FSAR) is received from the SDK platform. Within theFSAR, in one or more example approaches, the SDK platform discloses theoutcome resulting from the execution of the requested adjustment to thesoftware application. The FSAR is discussed in further detail below andin FIG. 5 .

FIG. 4B shows a method for generating a feature switching action advice(FSAA) in accordance with one or more aspects of the present disclosure.In Step 420, a service status report (SSR) is received from a serviceprovider. Further, in Step 422, a determination is made whetherinformation in the received SSR warrants that adjustment(s) of softwareapplication attributes take place. If at least one attribute or featureof a service is identified as requiring an adjustment, the processproceeds to Step 424; otherwise, it is deemed that feature switching isunnecessary and the process ends. For discussion detailing Steps 420 and422, refer to Steps 402 and 404 in FIG. 4A (discussed above) as theformer steps are substantially similar to the latter steps.

In Step 424, based on the determination presented in Step 422, a featureswitching action advice (FSAA) is generated by the SDK platform. TheFSAA serves to propose a recommended action, to convey to a commandauthority (e.g., application developer, developer device, a separatesystem 100 computer, a processor in the SDK platform, based on theindicators extracted from processing the SSR (discussed above).Moreover, presentation of the FSAA to the command authority may vary. Inone example approach, if it is deemed necessary that all recommendationsbe approved by the application developer, the FSAA is an interactivedialog that pops up in the developer UI (204 in FIG. 2A). In anotherexample approach, the FSAA is file or data stream that can be furtherprocessed and validated by a command authority.

Proceeding along, in Step 426, the FSAA, generated in Step 424, is sentto the command authority (e.g., application developer, developer device,a separate system 100 computer, a processor in the SDK platform.Following the processing of the FSAA by the command authority, a FSA isreceived from said command authority specifying the allowance,rejection, or replacement of the proposed action given by the SDKplatform. Therefore, if an allowance is granted, the SDK platform, forexample, may receive a FSA that instructs the SDK platform to implementthe recommended action. Conversely, a FSA may be received instructingthe SDK platform to not pursue the recommendation and stand idle if arejection is issued. Additionally, a received FSA may include analternative action that the command authority wishes to implement incontrast to the proposed action presented in the FSAA. Finally, in Step430, following the completion of processes shown and discussed belowwith respect to FIGS. 5 and 7 , a FSAR is transmitted to the commandauthority. The FSAR is discussed in further detail below and in FIG. 5 .

FIG. 5 shows a method for generating a feature switching instruction(FSI) and a feature switching action response (FSAR) in accordance withone or more aspects of the present disclosure. In Step 502, a featureswitching action (FSA) (discussed above) is received from a commandauthority. In Step 504, a set of user devices is identified using theFSA. In one example approach, using the tracking of deployed SDKsfunctionality of the SDK platform (see e.g., discussion of SDK platformwith regards to FIG. 1 ), a command authority may identify user devicesby determining which are running applications with an SDK and/or afeature addressed by the FSA. In another example approach, theidentification of user devices may be determined prior to the processshown in FIG. 5 .

In Step 506, one or more feature switching instructions (FSIs) aregenerated based on the FSA. In one example approach, each FSI may beinterpreted differently by user devices with differing architectures,and therefore, each FSI may be generated with consideration to theembedded hardware and/or software specifications on the particular userdevice in mind. For example, if different operating systems (OS) (i.e.,iOS®, Android™, Windows®, etc.) are found running on the set of userdevices that are targeted to apply an adjustment of a feature, variousFSI are generated utilizing the programming language native to each OS.(iOS is a registered trademark of Cisco Systems, Inc., Android is atrademark of Google, Inc., and Windows is a registered trademark ofMicrosoft Corporation). Furthermore, in one example approach, the FSImay include, but is not limited to, the following information items: (i)a unique service SDK identifier, derived from the unique serviceprovider identifier within the received FSA, and used by the softwareapplication, in the user device, as to which service to perform theadjustment(s); (ii) one or more feature identifier and set value pairsidentified in the received FSA (discussed above); and (iii) a userinterface (UI) skin index, which is used by the feature switchingmanager, pertaining to the service SDK matching the unique service SDKidentifier, in the user device to obtain one of various UI skins storedin the resources repository (see e.g., 248 in FIG. 2C) included in theservice SDK. In another example approach, instead of a UI skin index,the FSI may alternatively include a UI skin itself, further implyingthat in one example approach, UI skins may not be a resource availablelocally by the corresponding service SDK.

In Step 508, the one or more FSIs, generated in Step 506, aretransmitted to the set of user devices identified in Step 504. Further,in Step 510, following the completion of processes shown and discussedbelow with respect to FIG. 7 , one or more feature switching instructionresponses (FSIR) are received from the identified user devices (Step504). Within the FSIR, in one or more example approaches, eachidentified user device discloses the outcome resulting from theexecution of the requested adjustments in the releases of the softwareapplication. The FSIR is discussed in further detail below and in FIG. 7.

In Step 512, a feature switching action response (FSAR) is generatedbased on the aggregate FSIR received from the various identified userdevices. In one or more example approaches, the FSAR entails a summaryof the outcomes resulting from the execution of the requestedadjustments on each identified user device. By way of an example, theFSAR may provide information corresponding to the particular outcomerecorded by each of the identified user devices (Step 504). In anotherexample, the FSAR may only highlight information from a subset of theidentified user devices, which have experienced undesired outcomes(e.g., failures, errors). Further the FSAR may be transmitted as a filein one example approach, whereas it may be transmitted as a data streamin another example approach. The transmission of the FSAR to a commandauthority takes place in Step 514.

FIGS. 6A-6C show varying examples of degrees of granularity granted infeature switching, with respect to the targeting of user devices, inaccordance with one or more aspects of the present disclosure. Further,each degree of granularity shown portrays like-named components commonwithin each example. These common components include: (i) a commandauthority/SDK platform component (600A, 600B, 600C), stressing that thetargeting of user devices may be determined by either the commandauthority (e.g., application developer, developer device) or the SDKplatform; and (ii) a representation of user devices (602A, 602B, 602C)that are executing the involved software application. In the examplepresented in FIG. 6A, it is conveyed that the command authority or SDKplatform (600A) is capable of targeting an individual user device. Thiscase may occur, for example, when the presentation of adjustments,specifically with regard to content and data, may be tailored to theobserved activities and preferences of the individual user. Moreover,FIG. 6B shows that targeting can be definable to a subset of userdevices. An example of this scenario may include the performance ofanalytics on experience data gathered by the service SDK in each userdevice, thereby prompting the formation of sets of user devices (e.g.,users) that exhibit similar behavior or share the same hardware and/orsoftware specifications. Adjustments formulated based on thosecommonalities are then directed to those sets. Finally, in FIG. 6C, thecommand authority or SDK platform (600C) includes functionality totarget all user devices running the associated software application. Anevent triggering an action affecting all user devices, such as thehacking, and subsequent security breach, of a service, serves toexemplify a condition where all users must be safeguarded.

FIG. 7 shows a method for generating a feature switching instructionresponse (FSIR) in accordance with one or more aspects of the presentdisclosure. In Step 702, a feature switching instruction (FSI)(discussed above) is received from the SDK platform. In Step 704,processing is done on the received FSI to identify at least the serviceSDK the instruction is intended for, and one or more feature and setvalue pairs detailing the instructions that need to be executed on a perfeature basis. In one example approach, each feature and set value pairmay be presented as a tuple of information consisting of a featureidentifier and a feature set value, where the feature set valuerepresents a quantifiable adjustment to the feature associated with thefeature identifier. A quantifiable adjustment, for example, may include,but is not limited to: (i) a binary indicator referencing the state(e.g., on or off) that is to be set on a feature; or (ii) a variable,numerical indicator referencing a set amount, a proportion, apercentage, etc. In one or more example approaches, processing refers tothe interpretation of the FSI by the feature switching manager of theintended service SDK. In Step 706, a determination is made whetherinformation in the received FSI warrants the necessity of a replacementUI skin (e.g., resources) to fulfill the execution of the instruction.If an adjustment is presented that affects the user interface of thesoftware application, the process proceeds to Step 708; otherwise, it isdeemed that any observable change in the user interface is unnecessary,and the process forwards to Step 712. In Step 708, based on thedetermination presented in Step 706, a replacement UI skin is obtained.As mentioned above, in one example approach, the received FSI mayinclude a replacement UI skin. In another example approach, the receivedFSI may alternatively include a replacement UI skin index, which can beused to search for and obtain a replacement UI skin associated with theindex, amongst a plurality of UI skins, included within the resourcesrepository (see e.g., 248 in FIG. 2C) of the identified service SDK(Step 704). The obtained replacement UI skin is then applied to the userinterface of the software application in Step 710. Alternatively, thedetermination presented in Step 706 may disclose that the received FSI(Step 702) does not necessitate a replacement UI skin (or otherresources) to complete the specified adjustment(s). Hence, in Step 712,based on the aforementioned determination, at least one feature and setvalue pair (discussed above) is identified from the FSI and appliedtowards fulfilling feature switching amongst the software application.

In Step 714, whether a replacement UI skin is required or not, followingeither path of the determination, properties of the affected feature(s)are updated accordingly. Properties of a feature, in one or more exampleapproaches, may include, but are not limited to: (i) visibility—definingwhether the feature should be accessible or inaccessible to theend-user; (ii) state—defining whether the feature is enabled or disabledas viewed by the components of the feature switching system (see e.g.,FIG. 1 ); and (iii) value—defining the current set value adopted by thefeature, either as a default set value or a set value presented by aninstruction. In Step 716, a feature switching instruction response(FSIR) is generated based on the outcome of the FSI execution. The FSIRmay represent an account and/or analysis of results subsequent to thefeature switching manager's execution of a FSI. In one or more exampleapproaches, FSI outcomes include: confirmation of the successfulimplementation of an adjustment, confirmation of the failedimplementation of an adjustment, and/or details outlining reasons forerrors that were encountered. The FSIR may be transmitted to the SDKplatform as a file or data stream, or any other mode of data transferwithout departing from what is described herein. Lastly, in Step 718,the FSIR, generated in Step 716, is transmitted to the SDK platform.

In one non-limiting example, an application executing on one of userdevices 220 may be configured to use three services. The services areexposed via SDKs 224 and 226 on user device 220. In one exampleapproach, when user device 220 wakes up (e.g., turns on), user device220 notifies SDK platform 108 that it is planning to use three services.SDK platform 108 contacts the providers of the three services (eitherdirectly or indirectly via, for example, a separate command authority)to obtain status and receives a service status report (SSR) from eachservice provider providing the service. If a service is not available,SDK platform 108 acts accordingly. For instance, if a phone expects aservice to be available and it is not, SDK platform 108 instructs userdevice 220 to turn off the service that is not available. If onlyaspects of the service are unavailable, SDK platform 108 instructs userdevice 220 to turn off the aspects of the service that are notavailable. In one such approach, an FSI is sent to the mobile device todisable the appropriate service or the appropriate aspects of theservice. User device 220 then confirms that it turned the feature off(via, for example, an FSIR).

In one example approach, a command authority/SDK platform component600A, 600B or 600C receives notice from user device 220 of services anapplication can access. Component 600A, 600B, or 600C requests status ofthe services from the appropriate service providers and notifies userdevice 220 if features are to be switched off due to, for instance,unavailable services.

In one particular example, system 100 may determine that, due to someworld event, traffic on the fabric will start spiking, potentiallyoverwhelming the system. In such a scenario, a decision might be madeto, for example, prevent new mobile applications from coming on line. Insome example approaches, such a decision is made by system 100 withoutinput from third party developers. In other example approaches, however,system 100 may rely on the third party application developer to indicatewhether a feature or service should be turned on or off; system 100 maythen determine if the feature or service will, in fact, be turned on oroff

The following examples are for explanatory purposes only and notintended to limit the disclosure. FIG. 8 shows one example of theexecution of a feature switching instruction (FSI) on a user device inaccordance with one or more aspects of the present disclosure. In thisexample, consider a scenario in which one of a plurality of paymentservices incorporated into a software application (802) experiencestechnical difficulties, forcing the corresponding service provider toenact unscheduled downtime of their service. Through the various stepsdiscussed above, a FSI is ultimately received by a user device (800) inresponse to notification of the downed payment service by thecorresponding service provider. More specifically, the FSI is receivedby the feature switching manager (814) of the service SDK (806)associated with the downed payment service. Accordingly, the featureswitching manager (814) processes the FSI to reveal that a userinterface (UI) skin index has been included in the FSI. As the presenceof this index implies that an adjustment must be made that requires theapplication of a replacement UI skin (818), the feature switchingmanager (814) accesses the resources repository (816) in the service SDK(806) of the downed payment service. From there, the feature switchingmanager (814) uses the provided UI skin index to search for and obtainthe corresponding replacement UI skin (818), amongst a plurality ofavailable UI skins, in the resources repository (816). Subsequently, thefeature switching manager (814) applies the obtained replacement UI skin(818) onto the user interface (804), where the adjustment of certainfeatures (810, 812) has led to a result which is observable to theend-user. That is to say, a replacement UI skin, opting out access to oruse of the downed payment service, by the user, was implemented. In oneexample approach, the user may still view the downed payment service inthe user interface (804), but is unable to select the option. In anotherexample approach, the replacement UI skin (818) does not display any ofthe payment service, as if the payment service was never offered.Lastly, the feature switching manager (814) accesses the properties(discussed above) associated with the affected features (810, 812) andupdates them accordingly.

FIG. 9 shows one example of the execution of a feature switchinginstruction (FSI) on a user device in accordance with one or moreaspects of the present disclosure. In this example, consider a scenarioin which the aggregation of social media is provided by a serviceimplemented in a software application (902). Furthermore, throughanalytics performed on usage data associated with the softwareapplication, a command authority recognizes that the user of the userdevice (900) is more attentive towards social media deriving from two ofthe plurality of sources feeding said media. Consequently, a FSI isreceived by the user device. The feature switching manager (914)belonging to a particular service SDK (908), amongst the plurality ofservice SDKs (908, 910) on the user device, is the target and proceedsto process the FSI. The result of the processing reveals that theadjustment does not require any resources (e.g., resources repository(916)) to execute the delivered instructions. Aside from thisdetermination, however, processing has also extracted a number offeature and set value pairs. Each pair corresponds to the percentage ofthe aggregated social media feed each source is to contribute. By way ofthis example, the aggregate social media feed is to be swayedpredominantly by two of the plurality of sources used by the service,whereas the contribution of media pertaining to the remaining sourcesdiminish. Consequently, the feature switching manager (914) requeststhat the service provider (918) assert the aforementioned contributionchanges. Ultimately, the data received by the service provider (918), inresponse to the request, is then stored in the local data repository(906), and accessed by the software application accordingly. The user,on the other hand, is not made aware of the changes, but experiencesbetter service based on their usage data patterns.

Aspects of the disclosure may be implemented on a computing system. Anycombination of mobile, desktop, server, embedded, or other types ofhardware may be used. For example, as shown in FIG. 10 , the computingsystem (1000) may include one or more computer processor(s) (1002),associated memory (1004) (e.g., random access memory (RAM), cachememory, flash memory, etc.), one or more storage device(s) (1006) (e.g.,a hard disk, an optical drive such as a compact disk (CD) drive ordigital versatile disk (DVD) drive, a flash memory stick, etc.), andnumerous other elements and functionalities. The computer processor(s)(1002) may be an integrated circuit for processing instructions. Forexample, the computer processor(s) may be one or more cores, ormicro-cores of a processor. The computing system (1000) may also includeone or more input device(s) (1010), such as a touchscreen, keyboard,mouse, microphone, touchpad, electronic pen, or any other type of inputdevice. Further, the computing system (1000) may include one or moreoutput device(s) (1008), such as a screen (e.g., a liquid crystaldisplay (LCD), a plasma display, touchscreen, cathode ray tube (CRT)monitor, projector, or other display device), a printer, externalstorage, or any other output device. One or more of the output device(s)may be the same or different from the input device(s). The computingsystem (1000) may be connected to a network (1012) (e.g., a local areanetwork (LAN), a wide area network (WAN) such as the Internet, mobilenetwork, or any other type of network) via a network interfaceconnection (not shown). The input and output device(s) may be locally orremotely (e.g., via the network (1012)) connected to the computerprocessor(s) (1002), memory (1004), and storage device(s) (1006). Manydifferent types of computing systems exist, and the aforementioned inputand output device(s) may take other forms.

Software instructions in the form of computer readable program code toperform what is described herein may be stored, in whole or in part,temporarily or permanently, on a non-transitory computer readable mediumsuch as a CD, DVD, storage device, a diskette, a tape, flash memory,physical memory, or any other computer readable storage medium.Specifically, the software instructions may correspond to computerreadable program code that when executed by a processor(s), isconfigured to perform aspects of the disclosure.

Further, one or more elements of the aforementioned computing system(1000) may be located at a remote location and connected to the otherelements over a network (1012). Further, in some example approaches,system 1000 may be implemented on a distributed system having aplurality of nodes, where each aspect of the disclosure may be locatedon a different node within the distributed system. In example approach,the node corresponds to a distinct computing device. Alternatively, thenode may correspond to a computer processor with associated physicalmemory. The node may alternatively correspond to a computer processor ormicro-core of a computer processor with shared memory and/or resources.

In one or more examples, the functions described above may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored on ortransmitted over, as one or more instructions or code, acomputer-readable medium and executed by a hardware-based processingunit. Computer-readable media may include computer-readable storagemedia, which corresponds to a tangible medium such as data storagemedia, or communication media including any medium that facilitatestransfer of a computer program from one place to another, e.g.,according to a communication protocol. In this manner, computer-readablemedia generally may correspond to (1) tangible computer-readable storagemedia, which is non-transitory or (2) a communication medium such as asignal or carrier wave. Data storage media may be any available mediathat can be accessed by one or more computers or one or more processorsto retrieve instructions, code and/or data structures for implementationof the techniques described in this disclosure. A computer programproduct may include a computer-readable medium.

By way of example, and not limitation, such computer-readable storagemedia can comprise random access memory (RAM), read only memory (ROM),electrically erasable programmable read-only memory (EEPROM), compactdisc read-only memory (CD-ROM) or other optical disk storage, magneticdisk storage, or other magnetic storage devices, flash memory, or anyother medium that can be used to store desired program code in the formof instructions or data structures and that can be accessed by acomputer. Also, any connection is properly termed a computer-readablemedium. For example, if instructions are transmitted from a website,server, or other remote source using a coaxial cable, fiber optic cable,twisted pair, digital subscriber line (DSL), or wireless technologiessuch as infrared, radio, and microwave, then the coaxial cable, fiberoptic cable, twisted pair, DSL, or wireless technologies such asinfrared, radio, and microwave are included in the definition of medium.It should be understood, however, that computer-readable storage mediaand data storage media do not include connections, carrier waves,signals, or other transient media, but are instead directed tonon-transient, tangible storage media. Disk and disc, as used, includescompact disc (CD), laser disc, optical disc, digital versatile disc(DVD), floppy disk and Blu-ray disc, where disks usually reproduce datamagnetically, while discs reproduce data optically with lasers.Combinations of the above should also be included within the scope ofcomputer-readable media.

Instructions may be executed by one or more processors, such as one ormore digital signal processors (DSPs), general purpose microprocessors,application specific integrated circuits (ASICs), field programmablelogic arrays (FPGAs), or other equivalent integrated or discrete logiccircuitry. Accordingly, the term “processor,” as used may refer to anyof the foregoing structure or any other structure suitable forimplementation of the techniques described. In addition, in someaspects, the functionality described may be provided within dedicatedhardware and/or software modules. Also, the techniques could be fullyimplemented in one or more circuits or logic elements.

The techniques of this disclosure may be implemented in a wide varietyof devices or apparatuses, including a wireless handset, an integratedcircuit (IC) or a set of ICs (e.g., a chip set). Various components,modules, or units are described in this disclosure to emphasizefunctional aspects of devices configured to perform the disclosedtechniques, but do not necessarily require realization by differenthardware units. Rather, as described above, various units may becombined in a hardware unit or provided by a collection ofinteroperative hardware units, including one or more processors asdescribed above, in conjunction with suitable software and/or firmware.

It is to be recognized that depending on the embodiment, certain acts orevents of any of the methods described herein can be performed in adifferent sequence, may be added, merged, or left out altogether (e.g.,not all described acts or events are necessary for the practice of themethod). Moreover, in certain embodiments, acts or events may beperformed concurrently, e.g., through multi-threaded processing,interrupt processing, or multiple processors, rather than sequentially.

In some examples, a computer-readable storage medium includes anon-transitory medium. In some examples, the term “non-transitory”indicates that the storage medium is not embodied in a carrier wave or apropagated signal. In certain examples, a non-transitory storage mediummay store data that can, over time, change (e.g., in RAM or cache).Although certain examples are described as outputting variousinformation for display, techniques of the disclosure may output suchinformation in other forms, such as audio, holographical, or hapticforms, to name only a few examples, in accordance with techniques of thedisclosure.

While the invention has been described with respect to a limited numberof examples, those skilled in the art, having benefit of thisdisclosure, will appreciate that other example approaches can be devisedwhich do not depart from the scope of what is disclosed herein.Accordingly, the scope of the invention should be limited only by theattached claims.

1. (canceled)
 2. A method for feature switching in a softwareapplication for social media executing on a user device, the softwareapplication providing a user interface to display aggregated socialmedia content on the user device, the software application communicatingwith a set of services and executing a set of service softwaredevelopment kits (SDKs) corresponding to the set of services, the methodcomprising: receiving, by the software application on the user devicefrom a SDK platform, a feature switching instruction (FSI) for a firstservice of the set of services, the first service providing social mediacontent to the software application, the social media content beingaggregated from a plurality of sources; identifying, by the softwareapplication based on the FSI, a first service SDK of the set of serviceSDKs, the first service SDK corresponding to the first service, whereinthe FSI specifies a plurality of set values for the first service SDK,each set value of the plurality of set values corresponding to adifferent source of the plurality of sources and representing a relativecontribution of social media content from that source to the aggregatedsocial media content; and updating, by the software application, thefirst service SDK to provide the aggregated social media content to thesoftware application according to the plurality of set values.
 3. Themethod of claim 2, further comprising: generating, by the softwareapplication, a feature switching instruction response (FSIR) fortransmission to the SDK platform, the FSIR indicating an outcomeassociated with the execution, by the user device, of updating the firstservice SDK based on the FSI.
 4. The method of claim 2, wherein updatingthe first service SDK comprises: generating, by the softwareapplication, a request for transmission to a service provider to providethe aggregated social media content according to the plurality of setvalues; receiving, by the software application on the user device fromthe service provider, the aggregated social media content according tothe plurality of set values; and storing, by the software application onthe user device, the aggregated social media content in a local datarepository of the user device.
 5. The method of claim 2, wherein: theplurality of set values is a first plurality of set values; and themethod further comprises, before receiving the FSI at the user device:receiving, by the software application on the user device, theaggregated social media content according to a second plurality of setvalues, each set value of the of the second plurality of set valuescorresponding to a different source of the plurality of sources andrepresenting a relative contribution of social media content from thatsource to the aggregated social media content, wherein at least one setvalue of the second plurality of set values corresponding to a givensource of the plurality of sources is different from its correspondingset value of the first plurality of set values corresponding to thatgiven source.
 6. The method of claim 2, wherein: the plurality of setvalues is a first plurality of set values; the plurality of sources is afirst plurality of sources, the first plurality of sources comprising: asecond plurality of sources; and a new source introduced by the FSI; andthe method further comprises, before receiving the FSI at the userdevice: receiving, by the software application on the user device, theaggregated social media content according to a second plurality of setvalues, each set value of the of the second plurality of set valuescorresponding to a different source of the second plurality of sourcesand representing a relative contribution of social media content fromthat source to the aggregated social media content.
 7. The method ofclaim 2, further comprising, before receiving the FSI at the userdevice: receiving, at the SDK platform, a feature switching action (FSA)from a command authority authorizing feature switching of the softwareapplication, the SDK platform being authorized to execute the featureswitching of the software application, the FSA comprising a user deviceidentifier and the plurality of set values; identifying, by the SDKplatform, the user device based on the user device identifier in thereceived FSA; generating, by the SDK platform, the FSI with theplurality of set values based on the received FSA for the user device;and sending, from the SDK platform to the user device, the FSI.
 8. Themethod of claim 2, further comprising: generating, by the SDK platform,a feature switching action response (FSAR) based on the FSIR, the FSARindicating, when updating the first service SDK is not successful, anoutcome associated with the execution, by the SDK platform, of thefeature switching of the software application on the user device basedon the FSI sent to the user device; and sending, from the SDK platformto a command authority, the FSAR.
 9. The method of claim 2, wherein: theSDK platform provides an application marketplace to facilitate exchangeof software applications from a developer device to the user device; andthe method further comprises, before receiving the FSI at the userdevice: receiving, at the user device from the application marketplaceof the SDK platform, the software application.
 10. The method of claim2, wherein: each service SDK of the set of service SDKs includes one ormore features and corresponds to one service of the set of services; andthe method further comprises: determining, by the SDK platform, at leastone of: the set of service SDKs installed on the user device; for eachservice SDK of the set of service SDKs, an amount of time each featureof the one or more features is executed; for each service SDK of the setof service SDKs, an identity of a subset of features of the one or morefeatures that is executed; for each service SDK of the set of serviceSDKs, a frequency that a service corresponding to that service SDK isaccessed; an operating system of the user device; or a geographiclocation of the user device.
 11. The method of claim 2, furthercomprising, before generating the FSIR: identifying, by the softwareapplication on the user device based on the FSI, a second service SDK ofthe set of service SDKs, the second service SDK corresponding to asecond service of the set of services, wherein the FSI specifies a setvalue for the second service SDK, the set value indicating the secondservice SDK is to be disabled due to the second service exceeding athreshold for downtime; and disabling, by the software application onthe user device, the second service SDK based on the set value for thesecond service SDK.
 12. A method for feature switching in a softwareapplication executing on a first user device of a set of user devices,each user device of the set of user devices executing the softwareapplication, the method comprising: receiving, at a software developmentkit (SDK) platform, a feature switching action (FSA) from a commandauthority authorizing feature switching of the software application, theSDK platform being authorized to execute the feature switching of thesoftware application, the FSA comprising at least one user deviceidentifier and a plurality of set values; identifying, by the SDKplatform, the first user device based on the at least one user deviceidentifier in the received FSA; and for the first user device:generating, by the SDK platform, a feature switching instruction (FSI)with the plurality of set values based on the received FSA; and sending,from the SDK platform to the first user device, the FSI.
 13. The methodof claim 12, further comprising: receiving, at the SDK platform from thefirst user device, a feature switching instruction response (FSIR);generating, by the SDK platform, a feature switching action response(FSAR) based on the received FSIR, the FSAR indicating an outcomeassociated with the execution, by the SDK platform, of the featureswitching of the software application on the first user device based onthe FSI sent to the first user device; and sending, from the SDKplatform to the command authority, the FSAR.
 14. The method of claim 12,wherein: the software application is for social media and provides auser interface to display aggregated social media content on the firstuser device; the software application communicates with a set ofservices and includes a set of service software development kits (SDKs)corresponding to the set of services; the FSI is for a first service ofthe set of services, the first service providing social media content tothe software application, the social media content being aggregated froma plurality of sources; and the method further comprises: identifying,by the software application on the first user device based on the FSI, afirst service SDK of the set of service SDKs, the first service SDKcorresponding to the first service, the plurality of set values beingspecified for the first service SDK, each set value of the plurality ofset values corresponding to a different source of the plurality ofsources and representing a relative contribution of social media contentfrom that source to the aggregated social media content; and updating,by the software application on the first user device, the first serviceSDK to provide the aggregated social media content to the softwareapplication according to the plurality of set values.
 15. The method ofclaim 14, wherein updating the first service SDK comprises: generating,by the software application on the first user device, a request fortransmission to a service provider to provide the aggregated socialmedia content according to the plurality of set values; receiving, bythe software application on the first user device from the serviceprovider, the aggregated social media content according to the pluralityof set values; and storing, by the software application on the firstuser device, the aggregated social media content in a local datarepository of the first user device.
 16. The method of claim 14,wherein: the plurality of set values is a first plurality of set values;and the method further comprises, before receiving the FSI at the userdevice: receiving, by the software application on the user device, theaggregated social media content according to a second plurality of setvalues, each set value of the of the second plurality of set valuescorresponding to a different source of the plurality of sources andrepresenting a relative contribution of social media content that sourcecontributes to the aggregated social media content, wherein at least oneset value of the second plurality of set values corresponding to a givensource of the plurality of sources is different from its correspondingset value of the first plurality of set values corresponding to thatgiven source.
 17. The method of claim 14, wherein: the plurality of setvalues is a first plurality of set values; the plurality of sources is afirst plurality of sources, the first plurality of sources comprising: asecond plurality of sources; and a new source introduced by the FSI; andthe method further comprises, before receiving the FSI at the first userdevice: receiving, by the software application on the first user device,the aggregated social media content according to a second plurality ofset values, each set value of the of the second plurality of set valuescorresponding to a different source of the second plurality of sourcesand representing a relative contribution of social media content thatsource contributes to the aggregated social media content.
 18. Themethod of claim 12, wherein: the software application communicates witha set of services and executes a set of service software developmentkits (SDKs), each service SDK of the set of service SDKs including oneor more features and corresponding to one service of the set ofservices; and the method further comprises: determining, by the SDKplatform for each user device of the set of user devices, at least oneof: the set of service SDKs installed on the user device; for eachservice SDK of the set of service SDKs, an amount of time each featureof the one or more features is executed; for each service SDK of the setof service SDKs, an identity of a subset of features of the one or morefeatures that is executed; for each service SDK of the set of serviceSDKs, a frequency that a service corresponding to that service SDK isaccessed; an operating system of that user device; or a geographiclocation of that user device.
 19. The method of claim 12, furthercomprising: identifying, by the software application on the first userdevice based on the FSI, a first service SDK of the set of service SDKs,the first service SDK corresponding to a first service of the set ofservices, wherein the plurality of set values includes a first set valuefor the first service SDK, the set value indicating the first serviceSDK is to be disabled due to the first service exceeding a threshold fordowntime; and disabling, by the software application on the first userdevice, the first service SDK based on the set value for the firstservice SDK.
 20. A non-transitory computer readable medium storinginstructions for, when executed on a user device, feature switching in asoftware application for social media executing on the user device, thesoftware application providing a user interface to display aggregatedsocial media content on the user device, the software applicationcommunicating with a set of services and executing a set of servicesoftware development kits (SDKs) corresponding to the set of services,the instructions, when executed, cause at least one processor to:receive, by the software application on the user device from a SDKplatform, a feature switching instruction (FSI) for a first service ofthe set of services, the first service providing social media content tothe software application, the social media content being aggregated froma plurality of sources; identify, based on the FSI, a first service SDKof the set of service SDKs, the first service SDK corresponding to thefirst service, wherein the FSI specifies a plurality of set values forthe first service SDK, each set value of the plurality of set valuescorresponding to a different source of a plurality of sources andrepresenting a relative contribution of social media content from thatsource to the aggregated social media content; and update the firstservice SDK to provide the aggregated social media content to thesoftware application according to the plurality of set values.
 21. Thenon-transitory computer readable medium of claim 20, wherein theinstructions, when executed, further cause at least one processor to:generate a feature switching instruction response (FSIR) fortransmission to the SDK platform, the FSIR indicating an outcomeassociated with the execution of updating the first service SDK based onthe FSI.
 22. The non-transitory computer readable medium of claim 20,wherein the instructions to update the first service SDK, when executed,cause the at least one processor to: generate a request for transmissionto a service provider to provide the aggregated social media contentaccording to the plurality of set values; receive, from the serviceprovider, the aggregated social media content according to the pluralityof set values; and store the aggregated social media content in a localdata repository of the user device.
 23. The non-transitory computerreadable medium of claim 20, wherein: the plurality of set values is afirst plurality of set values; and the instructions, when executed,further cause the at least one processor to, before receiving the FSI atthe user device: receive the aggregated social media content accordingto a second plurality of set values, each set value of the of the secondplurality of set values corresponding to a different source of theplurality of sources and representing a relative contribution of socialmedia content from that source to the aggregated social media content,wherein at least one set value of the second plurality of set valuescorresponding to a given source of the plurality of sources is differentfrom its corresponding set value of the first plurality of set valuescorresponding to that given source.
 24. The non-transitory computerreadable medium of claim 20, wherein: the plurality of set values is afirst plurality of set values; the plurality of sources is a firstplurality of sources, the first plurality of sources comprising: asecond plurality of sources; and a new source introduced by the FSI; andthe instructions, when executed, further cause the at least oneprocessor to, before receiving the FSI at the user device: receive theaggregated social media content according to a second plurality of setvalues, each set value of the of the second plurality of set valuescorresponding to a different source of the second plurality of sourcesand representing a relative contribution of social media content fromthat source to the aggregated social media content.